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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The present document defines the coding of information in an extension of the Base Station System AppHcation Part 
(BSSAP) that is needed to support location services on interfaces based on use of BSSAP. 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document specifies procedures and information coding that are needed to define and support the BSSAP 
LCS Extension (BSSAP-LE). The BSSAP-LE message set is appHcable to the following GSM interfaces defined in 
3GPP TS 43.059: 

- Lb interface (BSC-SMLC). 

- Lp interface (SMLC-SMLC). 

The present document defines message formats and encoding for BSSAP-LE and the particular subsets of it that are 
applicable to each of the above interfaces. The present document also defines the support for BSSAP-LE message 
transfer on each of these interfaces using ITU-T and ANSI versions of SS7 MTP and SCCP. Additional requirements 
for the above interfaces that are applicable to BSSAP-LE are also defined - e.g. usage of BSSAP (as defined in 
3GPP TS 24.008 and 48.008) on the Lb interface. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[1] 3GPP TR 2L905: "Vocabulary for 3GPP Specifications". 

[la] 3GPP TS 23.032: "Universal Geographical Area Description (GAD)". 

[2] 3GPP TS 43.059: "Functional Stage 2 Description of Location Services in GERAN". 

[3] 3GPP TS 44.018: "Mobile radio interface layer 3 specification; Radio Resource Control Protocol". 

[3a] 3GPP TS 24.008: "Mobile radio interface layer 3 specification; Core Network Protocols; Stage 3". 

[4] 3GPP TS 44.03 1 : "Location Services (LCS); Mobile Station (MS) - Serving Mobile Location 

Center (SMLC); Radio Resource LCS Protocol (RRLP)". 

[5] 3GPP TS 44.071: "Location Services (LCS); Mobile radio interface layer 3 Location Services 

(LCS) specification". 

[6] 3GPP TS 48.006: "Signaling transport mechanism specification for the Base Station system - 

Mobile-services Switching Centre (BSS - MSC) interface". 

[7] 3GPP TS 48.008: "Mobile-services Switching Centre - Base Station System (MSC-BSS) 

interface; Layer 3 specification". 

[8] 3GPP TS 48.03 1 : "Location Services (LCS); Serving Mobile Location Center - Serving Mobile 

Location Center (SMLC - SMLC); SMLC specification". 

[9] 3GPP TS 48.071: "Serving Mobile Location Center - Base Station Subsystem (SMLC -BSS) 

interface Layer 3 specification". 

[10] 3GPP TS 29.002: "Mobile Apphcation Part (MAP) specification". 

[10a] 3GPP TS 23.003: "Numbering, addressing and identification". 
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[11] ITU-T Recommendation Q.702: "Signalling data link" . 

[ 1 2] ITU-T Recommendation Q.703 : "Signalling link" . 

[13] ITU-T Recommendation Q.704: "Signalling network functions and messages". 

[14] ITU-T Recommendation Q.707: "Testing and maintenance". 

[15] ITU-T Recommendation Q.711: "Functional description of the signalling connection control part" . 

[16] ITU-T Recommendation Q.712: "Definition and function of signalling connection control part 

messages". 

[17] ITU-T Recommendation Q.713: "Signalling connection control part formats and codes". 

[18] ITU-T Recommendation Q.714: "Signalling connection control part procedures". 

[19] ANSI Tl.lll (1996): "Signalling System Number 7 (SS7) - Message Transfer Part (MTP)". 

[20] ANSI Tl.l 12 (1996): "Signalling System Number 7 (SS7) - Signalling Connection Control Part 

(SCCP)". 

[21] TlA/ElA/lS-J-STD-036 (2000): "Wireless Enhanced Emergency Services". 

3 Definitions, abbreviations and symbols 

For the purposes of the present document, the definitions, symbols and abbreviations used in the present document are 
listed in 3GPP TS 21.905 and 3GPP TS 43.059. 



Definition of BSSAP-LE 



BSSAP-LE is an extension to BSSAP that contains messages and parameters specific to the support of LCS. The 
following subsets of BSSAP-LE are defined: DTAP-LE, BSSMAP-LE. 



4.1 DTAP-LE Messages 



DTAP-LE messages are transfered between an SMLC and a Type A LMU and comprise the following individual 

messages: 

- REGISTER; 

- FACILITY; 

- RELEASE COMPLETE. 

The content, encoding and certain procedures asssociated with DTAP-LE messages are defined in 3GPP TS 44.071. 

4.2 BSSMAP-LE Messages 

BSSMAP-LE messages are transferred between a BSC and SMLC and comprise the following individual messages: 
BSSMAP-LE Positioning Messages: 

Perform Location Request; 

Perform Location Response; 

Perform Location Abort. 
BSSMAP-LE Information Messages: 



£75/ 



3GPP TS 49.031 version 4.3.0 Release 4 9 ETSI TS 149 031 V4.3.0 (2002-07) 

Connection Oriented Information; 
Connectionless Information. 
BSSMAP-LE General Messages: 
Reset; 

Reset Acknowledge. 
The content and encoding of BSSMAP-LE messages are defined in the present document. 

5 Procedures applicable to use of BSSAP-LE 

5.1 Location Request 

The Location Request procedure is applicable to the Lb interface. Its purpose is to obtain a location estimate for a target 
MS that is already in dedicated mode. It is also used to provide an MS with LCS assistance data or with a deciphering 
key for LCS broadcast assistance data. The initiator of a location request is the serving BSC for the MS. The procedure 
makes use of SCCP connection oriented signaling on the Lb interface. 

5.1.1 Successful Operation 

The initiator of the location request (serving BSC) sends a BSSMAP-LE Perform Location Request to the SMLC 
associated with the current serving cell for the target MS. The message contains the following mandatory (M), 
conditional (C) and optional (O) information, where conditional parameters are required if available. 

Location Type (M); 

- Cell Identifier (M); 

Classmark Information Type 3 (C); 

- LCS Client Type (C); 
Chosen Channel (C); 

- LCS Priority (C); 

- LCS QoS (C); 

Requested GPS Assistance Data (C); 

- BSSLAP APDU (C). 

If requested, the SMLC performs positioning of the target MS using a particular position method or a combination of 
more than one positioning method. If the Classmark Information Type 3 IE is not present, the SMLC shall instigate only 
network based positioning methods (e.g. TA but not GPS or E-OTD). Alternatively, if requested otherwise, the SMLC 
may provide positioning assistance data to the MS. The SMLC may invoke the following other BSSAP-LE procedures 
to perform these procedures: 

connection oriented information transfer; 

connectionless information transfer; 

LMU connection establishment; 

LMU connection release; 

DTAP-LE information transfer. 

Additional procedures defined in 3GPP TS 24.008 and 3GPP TS 48.008 may also be performed. If a location estimate 
was requested and was subsequently obtained satisfying the required LCS QoS, the SMLC shall return a BSSMAP-LE 
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Perform Location Response to the initiator of the location request (serving BSC). This message contains the following 
mandatory, conditional and optional parameters. 

Location Estimate (M); 

Positioning Data (C). 

Restrictions on the geographic shape encoded within the Location Estimate parameter may exist for certain LCS client 
types. The SMLC shall comply with any restrictions defined in 3GPP Release 4 and, in a particular country, with any 
restrictions defined for a specific LCS client type in relevant national standards. For example, in the US, national 
interim standard TIA/EIA/IS-J-STD-036 restricts the geographic shape for an emergency services LCS client to 
minimally either an "ellipsoid point" or an "ellipsoid point with uncertainty circle and confidence" as defined in 3GPP 
TS 23.032. 

If assistance data was instead requested for an MS and the SMLC was able successfully to transfer this to the MS, the 
SMLC shall return a BSSMAP-LE Perform Location Response to the initiator of the location request (serving BSC). 
This message shall contain no parameters. The absence of an LCS Cause parameter in this case implies that the transfer 
was successful. 

Otherwise, if a deciphering key was requested for LCS broadcast assistance data and the SMLC has access to the 
appropriate keys, the SMLC shall return a BSSMAP-LE Perform Location Response to the initiator of the location 
request (serving BSC). This message contains the following mandatory parameters. 

Deciphering Keys (M). 



5.1.2 Unsuccessful Operation 



If the SMLC is unable to obtain any of the location information requested or none of the information obtained satisfies 
the requested LCS QoS or if requested LCS assistance data could not be transferred or requested deciphering keys for 
broadcast assistance data could not be returned, the SMLC shall return a BSSMAP-LE Perform Location Response to 
the initiator of the Location Request carrying the following parameters: 

- LCS Cause (M); 

Positioning Data (O). 

If assistance data or deciphering keys for a specific positioning method is not supported in the network or in the location 
area, the SMLC shall indicate this with LCS Cause value "Position method failure" accompanied with diagnostic value 
"Position Method Not Available in Network" or "Position Method Not Available in Location Area". 

5.1.3 Abnormal Conditions 

If an ongoing location request is preempted at the initiator by an inter-BSC handover or if the main signaling link to the 
target MS is lost or released or if there is a timeout waiting for the positioning response, the initiator shall send a 
BSSMAP-LE Perform Location Abort to the SMLC containing the following parameters. 

- LCS Cause (M). 

On receipt of this message, the SMLC shall stop positioning of the target MS and may release any resources 
(e.g. LMUs) previously allocated. If the SMLC has not yet returned a BSSMAP-LE Perform Location Response to the 
initiator, it shall return this message containing an LCS Cause indicating an abort and, optionally, positioning data. The 
initiator shall then release the SCCP connection. If the SMLC cannot proceed with positioning due to some protocol 
violation or error condition (e.g. inter-BSC handover indication received from the serving BSC), it shall return a 
BSSMAP-LE Perform Location Response to the initiator containing an LCS cause and, optionally, positioning data. 
The initiator need not reply at the BSS AP-LE level to this message. However, the initiator may return a BSSMAP-LE 
perform Location Abort which shall not be treated as an error by the SMLC. 

5.1.4 Overload 

If the SMLC is in an overload condition, it may reject a BSSMAP-LE Perform Location request by returning a 
BSSMAP-LE Perform Location response containing an LCS Cause parameter indicating congestion. The initiator of the 
location service request (BSC) may reduce the frequency of future location service requests until rejection due to 
overload has ceased. In reducing the frequency of location service requests, a BSC shall reduce lower priority requests. 
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to zero if necessary, before reducing the frequency of higher priority requests. An SMLC shall similarly reject location 
service requests of a lower priority, to zero if necessary, due to overload before rejecting location service requests of a 
higher priority. An SMLC in an overload condition may optionally employ the following procedures to alleviate 
overload: 

a) Allow higher priority location service requests to preempt lower priority requests for which location service 
procedures are already in progress. 

b) Abort lower priority location service requests already in progress. 

c) Reduce the supported QoS for lower priority requests for a location estimate - e.g. by reducing accuracy or 
increasing response time. 

d) Employ MS based positioning methods, where supported by the target MS and SMLC, rather than MS assisted 
or network based methods (except TA). 

The priority of a location service request shall be defined according to the value in the LCS Priority parameter. If this 
parameter is absent in a BSSMAP-LE Perform Location request, the lowest priority shall be assumed. 

5.2 Connection Oriented Information Transfer 

The Connection Oriented Information transfer procedure is applicable to the Lb interface. It enables two way transfer of 
BSSLAP messages between an SMLC and the BSC serving a target MS. The initiator of the procedure can be either the 
BSC serving the target MS or the SMLC. The procedure is only valid while a location request procedure for the target 
MS is ongoing. The procedure makes use of SCCP connection oriented signaling on the Lb interface and uses the same 
SCCP connection as the location request procedure for the particular target MS. 

5.2.1 Successful Operation 

An SMLC or BSC with a BSSLAP message or message segment to transfer concerning a particular target MS sends a 
BSSMAP-LE Connection Oriented Information message to a recipient carrying the following parameters: 

- BSSLAP APDU (M); 

Segmentation (C). 

If the sender is an SMLC, the message is transferred to the serving BSC for the target MS. The BSC shall then perform 
the positioning operation requested by the BSSLAP APDU (refer to 3GPP TS 48.071). If the BSSLAP APDU contains 
an RRLP APDU, the BSC shall transfer this to the target MS. 

If the sender is a BSC and the intended recipient is the SMLC for a target MS, the message is transferred to the SMLC. 
The SMLC shall then perform interpretation of the BSSLAP APDU. 

5.2.2 Abnormal Conditions 

At an intermediate entity, if a received BSSMAP-LE Connection Oriented Information message contains unrecognized 
information or if the message cannot be sent on, the message shall be discarded. 

At the receipient entity, if a received BSSMAP-LE Connectioin Oriented Information message contains invalid or 
unrecognized information as defined for BSSAP-LE, any ongoing positioning procedure shall be terminated and 
associated resources may be released. If the receipient is a BSC, the SMLC shall be notified - e.g. using a BSSLAP 
Reject or Abort. If the receipient is an SMLC, a new positioning attempt (e.g. using a different position method) may be 
started. 

5.2.3 Segmentation 

The Segmentation parameter shall not be included if the BSSLAP message is not segmented. 

If the size of an embedded BSSLAP message is too large to fit into one BSSMAP-LE message, the sending entity 
divides the BSSLAP message to a necessary number of BSSMAP-LE messages each containing a BSSLAP APDU IE 
and a Segmentation IE. In the BSSLAP APDU IE it includes as many octets as possible. 
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The segmentation IE contains a segment number field and an indication of the final segment. Message identification 
shall not be used. The order number of a segment in the Segment Number field in the Segmentation IE is incremented 
by one starting from zero, i.e. the value is for the first segment, 1 for the next and so on. The receiving entity may use 
the segment number in order to recognize the start of a new BSSLAP message and verify that all segments were reliably 
transferred. 

In case of handover interrupting the information transfer procedure, the exception procedures described in 
3GPP TS 43.059 shall be used. 

5.3 Connectionless Information Transfer 

The Connectionless Information transfer procedure is applicable to the Lb and Lp interfaces. It enables two way transfer 
of LLP messages between an SMLC and a Type B LMU. The procedure also enables two way transfer of SMLCPP 
messages between two SMLCs. The initiator of the procedure can be a BSC or SMLC. The procedure makes use of 
SCCP connectionless signaling. 

5.3.1 Successful Operation 

An SMLC or BSC needing to transfer an LLP message concerning a Type B LMU or an SMLCPP message sends a 
BSSMAP-LE Connectionless Information message to a recipient carrying the following parameters: 

- Source Entity (M); 
Destination Entity (M); 

- APDU (M); 

- Segmentation (C); 

Return Error Request (O). 

The source entity identifies the sender. The recipient entity identifies the final destination. The Segmentation IE 
provides segmentation and message identification for a segmented APDU. The Return Error Request may be included 
to request notification in the event of unsuccessful transfer and indicate the type of notification needed. If the recipient 
entity is not the final destination, the recipient shall transfer the BSSMAP-LE Connectionless Information message to 
either the final destination or an intermediate entity capable of onward transfer to the final destination. 

5.3.2 Unsuccessful Operation 

If the message cannot be transferred by an intermediate entity or destination entity (e.g. reassembly of a segmented 
message fails) and the Return Error Request is not included, the message shall be discarded. If the Return Error Request 
is included, the intermediate or destination entity shall, depending on the Return Error Request type, send a 
BSSMAP-LE Connectionless Information message to, or towards, the original source containing the following 
parameters: 

- Source Entity (M); 
Destination Entity (M); 

- APDU (C); 

- Segmentation (C); 

Return Error Cause (M). 

The Source entity shall indicate the Destination Entity in the original received message. The Destination Entity shall 
indicate the Source Entity in the original message. The Return Error cause shall indicate the reason for unsuccessful 
transfer. The APDU and Segmention lEs shall, depending on the Return Error Request type, contain any originally 
received APDU and Segmentation lEs, respectively. 

If a received BSSMAP-LE Connectionless Information message containing a Return Error Cause cannot be transferred 
by an intermediate entity, it shall be discarded with no return error message. 
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5.3.3 Abnormal Conditions 

At an intermediate entity, if a received BSSMAP-LE Connectionless Information message contains unrecognized or 
invalid information, the message shall be discarded. 

At the recipient entity, if a received BSSMAP-LE Connectionless Information message contains invalid or 
unrecognized information as defined for BSSAP-LE, the message shall be discarded. 

5.3.4 Segmentation 

The Segmentation parameter shall not be included if the APDU is not segmented. 

If the size of an APDU containing an embedded SMLCPP message is too large to fit into one BSSMAP-LE message, 
the sending entity divides the SMLCPP message to a necessary number of BSSMAP-LE messages each containing an 
APDU IE and a Segmentation IE. In the APDU IE it includes as many octets as possible. 

The segmentation IE contains a segment number, an indication of the final segment and the message ID. The order 
number of a segment in the Segment Number field in the APDU IE is incremented by one starting from zero, i.e. the 
value is for the first segment, 1 for the next and so on. The receiving entity recognizes that a segment is missing or 
duplicated, when: 

There is more than one segment with the same segment number and same Message ID. 

The segment number does not increase by steps of one starting from zero. 

If the recipient recognizes a missing or duphcated element, it shall discard the entire message (i.e. all received segment 
with the message ID). 

The message identity in the Message ID field in the APDU IE is used to recognize a particular message to which that 
segment belongs. The sending entity can select any of the available values (0-65535) that is not currently used between 
it and the receiving entity. 

If an APDU segment is received with Return Error cause IE (due to invocation of the return error option), reassembly 
does not apply and the APDU segment and error cause maybe returned to the original source application. 

5.4 LMU Connection Estabiisinment 

The LMU Connection Establishment procedure is applicable to the Ls interface. Its purpose is to establish a signaling 
connection between an SMLC and Type A LMU via the visted MSC for the LMU. The procedure can be initiated by 
either the SMLC or MSC. The procedure makes use of SCCP connection oriented signaling on the Ls interface. 

5.4.1 LMU Connection Establisliment initiated by tlie SMLC 
5.4.1.1 Successful Operation 

The SMLC sends a BSSMAP-LE LMU Connection Request message to the VMSC for the LMU. This message 
contains the following parameters. 

- IMSI (M); 
Sender Address (O); 

- Security (C). 

The IMSI identifies the LMU. The sender address, if included, identifies the SMLC. The Security parameter shall be 
included if authentication or ciphering of the LMU are required. On receipt of this message, the MSC shall attempt to 
establish a signalling link to the LMU (refer to 3GPP TS 43.071). Authentication and ciphering shall be invoked if 
requested by the SMLC. Once the signaling link has been established, the MSC shall return a BSSMAP-LE LMU 
Connection Accept to the SMLC with the following parameters. 

- Call Number (O). 
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The call number shall be included if the MSC has the capability to support signaling to an LMU using a traffic channel 
(refer to 3GPPTS 43.071). 

5.4.1.2 Unsuccessful Operation 

If the LMU is not recognized in the MSC (e.g. no VLR record) or a signaling link cannot be setup to the LMU 
(e.g. paging of the LMU fails) or authentication or ciphering cannot be performed when requested by the SMLC, any 
signaling link to the LMU shall be released, if not required for other MM or CM procedures and a BSSMAP-LE LMU 
Connection Reject shall be returned to the SMLC with the following parameters. 

- Reject Cause (M). 

5.4.1.3 Abnormal Conditions 

If the SMLC or MSC detects release of the SCCP connection on the Ls interface for an LMU, the connection 
establishment procedure shall be considered to have failed and any associated resources may be released. 

5.4.2 LMU Connection Establishment initiated by the MSC 

5.4.2.1 Successful Operation 

The MSC shall initiate the LMU connection establishment procedure when no LMU connection to the SMLC currently 
exists and the MSC receives a CM Service Request from the LMU specifying the LCS service. The MSC shall then 
send a BSSMAP-LE LMU Connection Request message to the SMLC associated with either the IMSI or current cell 
location of the LMU. This message shall contain the following parameters. 

- IMSI (M); 

- Sender Address (M); 

- Call Number (C). 

The IMSI identifies the LMU. The sender address identifies the MSC. The call number shall be included if the MSC has 
the capability to support signaling to an LMU using a traffic channel (refer to 3GPP TS 43.071). On receipt of this 
message, the SMLC shall return a BSSMAP-LE LMU Connection Accept to the MSC with the following parameters. 

- Security (C). 

The Security parameter shall be included if authentication or ciphering of the LMU are required On receipt of this 
message, the MSC shall perform authentication and/or ciphering if requested by the SMLC and shall complete the 
establishment of an MM connection to the LMU to support LCS. 

5.4.2.2 Unsuccessful Operation 

If the LMU is not recognized in the SMLC or a signaling connection cannot be supported (e.g. due to congestion), a 
BSSMAP-LE LMU Connection Reject shall be returned to the MSC with the following parameters. 

- Reject Cause (M). 

The MSC shall then reject the CM service request from the LMU. 

5.4.2.3 Abnormal Conditions 

If the SMLC or MSC detects release of the SCCP connection on the Ls interface for an LMU, the connection 
establishment procedure shall be considered to have failed and any associated resources may be released. 
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5.5 Void 

5.6 DTAP-LE Information Transfer 

The DTAP-LE Information transfer procedure is applicable to the Lb interface. It supports two way LLP message 
transfer between an SMLC and Type A LMU. The procedure is only valid when a signaling connection between an 
SMLC and Type A LMU has been established. The procedure uses SCCP connection oriented signaling using the 
SCCP connection previously established between the SMLC and BSC when the signaling connection between the 
SMLC and LMU was established. 

5.6.1 DTAP-LE Information Transfer Initiated by the SMLC 

The SMLC initiates the procedure when it has an LLP message to transfer to a type A LMU. The message may first be 
segmented. The SMLC shall then transfer each LLP segment to the BSC inside a DTAP-LE REGISTER, FACILITY or 
RELEASE COMPLETE message. The usage of these messages is as defined in 3GPP TS 44.071. The BSC relays each 
DTAP-LE message to the LMU. 

5.6.2 DTAP-LE Information Transfer Initiated by the BSC 

The BSC initiates the procedure when a DTAP message is received from an LMU. The BSC then relays the DTAP 
message to the SMLC. 

5.7 Reset 

The reset procedure is an optional procedure within a PLMN applicable to the Lb interface. It enables an SMLC or BSC 
that has undergone a failure with loss of memory of LMU signalling connections and location service transactions to 
indicate this to a partner entity (SMLC or BSC). The recipient entity can then release its own connection and transaction 
resources. The reset procedure may not be applicable when only a limited part of an SMLC or BSC has suffered a 
failure, since error recovery procedures specific to individual connections and transactions may then be used. 

5.7.1 Normal Operation 

In the event of a failure at an SMLC or BSC that results in the loss of LMU connection information and location service 
information, a Reset message may be sent to the partner SMLC or BSC across the Lb interface. The message carries no 
parameters and is sent using connectionless SCCP procedures. The sending entity shall ensure that all information on 
LMU connections and location service transactions to the other entity is reinitialized to indicate no existing connections 
and transactions. 

On receiving a Reset message, the recipient SMLC or BSC shall clear all references and state information for LMU 
connections and location service transactions to the sending entity and shall release any associated resources including, 
in the case of a recipient BSC, any signaling connections or circuit connections to LMUs controlled by a sending 
SMLC. The recipient entity shall then return a Reset Acknowledge message. 

For a reset on the Lb interface where the SMLC and BSC support circuit connections to LMUs (in addition to signaling 
connections), the entity that does not control assignment of circuits shall initiate blocking procedures (Block or Circuit 
Group Block procedure as defined in 3GPP TS 48.008) for all circuits that are locally blocked on its own side. The 
initiation of blocking may occur before sending or receipt, whichever applies, of the Reset Acknowledge. 

5.7.2 Abnormal Conditions 

If an initiating SMLC or BSC receives no response to a Reset message following an O&M administered time period, it 
shall resend the Reset message. For successive no response conditions, sending shall occur a maximum of "n" times, 
where "n" is an O&M administered parameter. Following "n" unsuccessful, reset attempts, the procedure shall be 
terminated and maintenance shall be informed. 
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6 Usage of BSSAP-LE and BSSAP on the Lb Interface 

6.1 Applicable Message Sets 

The following BSSAP-LE message sets are applicable to the Lb interface between an SMLC and BSC: 

- All DTAP-LE messages; 

All BSSMAP-LE positioning messages; 
All BSSMAP-LE information messages; 

- All BSSMAP-LE general messages. 

The following BSSMAP messages defined in 3GPP TS 48.008 are applicable to the Lb interface to support signaling to 
a Type A LMU using an SDCCH: 

- Cipher Mode Command (SMLC to B S C) ; 

- Cipher Mode Complete (B S C to SMLC) ; 

- Cipher Mode Reject (BSC to SMLC); 

- Classmark Update (BSC to SMLC); 

- Clear Command (SMLC to BSC); 

- Clear Complete (BSC to SMLC); 

- Clear Request (BSC to SMLC); 

- Complete Layer 3 Information (BSC to SMLC); 

- Confusion (BSC to SMLC); 

- Handover Required (BSC to SMLC); 

- Handover Required Reject (SMLC to BSC); 

- Handover Performed (BSC to SMLC); 

- Paging (SMLC to BSC). 

The following additional BSSMAP messages defined in 3GPP TS 48.008 are applicable to the Lb interface to support 
signaling to a Type A LMU using a TCH: 

- Assignment Request (SMLC to BSC); 

- Assignment Complete (BSC to SMLC); 

- Assignment Failure (BSC to SMLC); 
Block (two way); 

Blocking Acknowledge (two way); 

Unblock (two way); 

Unblocking Ack. (two way); 

Unequipped circuit (two way). 

The following DTAP messages defined in 3GPP TS 24.008 and 3GPP TS 44.018 are applicable to the Lb interface to 
support signaling to a Type A LMU using an SDCCH: 

RR Paging Response; 
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- All MM Messages. 

The following additional CM level DTAP messages defined in 3GPP TS 24.008 are applicable to the Lb interface to 
support signaling to a Type A LMU using a TCH. 

- Call Confirmed (LMU to SMLC); 

- Connect (LMU to SMLC); 

- Connect Acknowledge (SMLC to LMU); 

- Setup (SMLC to LMU); 
Disconnect (two way); 
Release (two way); 
Release Complete (two way). 

6.2 MTP Functions 

Except where defined otherwise in the present document, MTP requirements on the Lb interface for the BSC are the 
same as those defined for the A interface in 3GPP TS 48.006 for the BSC. MTP requirements on the Lb interface for the 
SMLC are the same as those defined for the A interface in 3GPP TS 48.006 for the MSC. STP functions are not 
required in the SMLC and a single signaling link set may be used between the BSC and SMLC. The BSC shall be 
homed to a single SMLC and shall only use the Lb signaling interface for signaling communication with the SMLC. 

6.3 SCCP Functions 

6.3.1 General 

Except where defined otherwise in the present document, SCCP requirements on the Lb interface for the BSC are the 
same as those defined for the A interface in 3GPP TS 48.006 for the BSC. SCCP requirements on the Lb interface for 
the SMLC are the same as those defined for the A interface in 3GPP TS 48.006 for the MSC. Requirements concerning 
support of a type A LMU are the same as those in 3GPP TS 48.006 regarding support of a normal MS. In particular, 
usage of SCCP to transfer DTAP-LE messages between a type A LMU and SMLC are the same as those regarding 
transfer of other DTAP messages. 

6.3.2 IVIodifications for Connectionless SCCP 

Connectionless SCCP messages and procedures are used to transfer BSSMAP-LE Connectionless Information 
messages and those BSSMAP messages applicable to the Lb interface for which connectionless SCCP transfer is 
defined in 3GPP TS 48.008. Refer to 3GPP TS 43.059 for a description of the procedures in the SMLC and BSC. SCCP 
protocol class 1 shall be used when multiple BSSMAP-LE messages are transferred containing segments of a single 
fragmented LLP or SMLCPP message. 

6.3.3 IVIodifications for Connection Oriented SCCP 

Use of connection oriented SCCP messages and procedures on the Lb interfaces to support signaling access to a type A 
LMU using DTAP-LE, DTAP and BSSMAP messages is the same as that defined in 3GPP TS 48.006 on the A 
interface to support access to a normal MS. 

To support positioning of a target MS, connection oriented SCCP messages and procedures using protocol class 2 shall 
be used to transfer BSSMAP-LE positioning messages and BSSMAP-LE Connection Oriented Information messages 
over the Lb interface. A separate dedicated SCCP connection shall be used to support positioning for each target MS. 
Connection establishment shall be instigated by the BSC when the positioning attempt commences. Connection release 
shall be instigated by either the BSC or SMLC when the positioning attempt has been completed or has failed. 
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Transfer of BSSMAP-LE messages using an SCCP connection to support positioning of a particular target MS is 
shown in the following figure. In particular, a BSSMAP-LE message shall be included in the data field of the SCCP 
CR and a BSSMAP-LE message may be included in the data field of an SCCP CC, CREF or RLSD message. 
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SMLC 



1. SCCP CR [BSSMAP-LE message] 



2. SCCP CREF [BSSMAP-LE message or no data] 
OR 
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4. SCCP RLSD [BSSMAP-LE message or no data] 
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5. SCCP RLC 



Figure 6.3.3/49.031 : SCCP Connection Oriented Signaling on Lb Interface for Positioning 

6.3.4 Contents of the SCCP Data Field 

The contents of the SCCP data field are the same as that defined for the A interface in 3GPP TS 48.006 for MSC-BSC 
signaling. In particular, the same conventions are used to transfer and discriminate between any BSSAP and DTAP 
message contained within the SCCP data field. Since all BSSAP-LE messages applicable to the Lb interface use the 
same encoding as for the A interface, the conventions used to discriminate a BSSMAP message are applicable to any 
BSSMAP-LE message on the Lb interface, while the conventions for a DTAP message apply to any DTAP-LE 
message. 

6.3.5 Abnormal Conditions 

If a user-out-of-service information or signalling-point-inaccessible information is received by a BSC or SMLC, no new 
attempt to establish SCCP connections towards the affected point code shall be started until the corresponding user-in- 
service information or signalling-point-accessible information is received. 

When a user-out-of-service information or signalling-point-inaccessible is received, an optional timer may be started. If 
the timer expires all the SCCP connections towards the affected point code shall be released. When the user-in-service 
or signalling-point-accessible is received, the timer is stopped. 

If an SCCP connection is released, the optional timer expires or a connection refusal is received, any dependent 
BSSAP-LE procedure between the SMLC and BSC shall be terminated and, at a BSC, any associated SCCP connection 
or location service transaction to an MSC, or any associated signaling or circuit connection to an LMU, shall be 
released using appropriate signalling procedures. 



7 



Void 
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8 Use of BSSAP-LE on the Lp Interface 

8.1 Applicable Message Sets 

The following BSSAP-LE messages are applicable to the Lp interface between an SMLC and a peer SMLC. 
BSSMAP-LE Connectionless Information message. 

8.2 MTP Functions 

SS7 signaling on the Lp interface may be supported using 56 kbps or 64 kbps digital signaling channels. These may be 
supported within either El or Tl physical links. 

Two SMLCs may be connected by direct point-to-point SS7 signaling links or links may be employed via intermediate 
STPs. Alternatively, signaling transfer between two SMLCs may be supported via intermediate BSCs and/or MSCs 
using the Lb and/or Ls interfaces. Signaling requirements to support message transfer on the Lp interface via an 
intermediate Lbinterface are the same as those defined elsewhere in the present document for these interfaces. This 
clause defines the requirements applicable to direct SMLC-SMLC SS7 links and SS7 links from an SMLC to an STP. 

For El links or where ITU-T/ITU SS7 signaling is applicable, the MTP functions as specified in ITU-T 
Recommendations Q.702, Q.703, Q.704 and Q.707 are applicable. For Tl links or where ANSI SS7 signaling is 
applicable, the MTP functions as specified in ANSI T 1.111 are applicable. Only the requirements in these 
recommendations for a signaling end point are applicable. 

Where an SMLC has no signaling links to an STP, certain exceptions and modifications to normal ITU-T and ANSI 
requirements may be applied within a PLMN administration. 

8.3 SCCP functions 

8.3.1 General 

For El links or where ITU-T/ITU SS7 signaling is applicable, the SCCP functions as specified in either ITU-T Blue 
Book Recommendations Q.71 1, Q.712, Q.713 and Q.714 or ITU White Book Recommendations Q.71 1, Q.712, Q.713 
and Q.714 are applicable, as amended by the exceptions and modifications defined here. For Tl links or where ANSI 
SS7 signaling is applicable, the MTP functions as specified in ANSI T1.112 are applicable, as amended by the 
exceptions and modifications defined here. 

8.3.2 Allowed Exceptions to ITU-T Recommendations Q.71 1 -71 4 

Only the following SCCP messages are applicable to the Lp interface: 
Inactivity Test (IT); 

- Subsystem Allowed (S S A) ; 

- Subsystem Prohibited (SSP); 

- Subsystem Status Test (SST); 

- Unitdata (UDT); 

- Unitdata Service (UDTS). 

Support of only SCCP protocol classes and 1 is required. 

The SCCP called party address in a UDT may contain only the subsystem number (SSN) or a signaling point code 
(SPC) plus SSN or a global title. Use of a global title is not required for SMLC to SMLC signaling within the same 
PLMN. SSN values applicable to the Lp interface are defined in 3GPP TS 23.003. 
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8.3.3 Allowed Exceptions to ANSI T1 . 11 2 

Only the following SCCP messages are applicable to the Lp interface: 
Inactivity Test (IT); 

- Subsystem Allowed (SSA); 

- Subsystem Prohibited (SSP); 

- Subsystem Status Test (SST); 

- Unitdata (UDT); 

- Unitdata Service (UDTS). 

Support of only SCCP protocol classes and 1 is required. 

The SCCP called party address in a UDT may contain only the subsystem number (SSN) or a signaling point code 
(SPC) plus SSN or a global title. Use of a global title is not required for SMLC to SMLC signaling within the same 
PLMN. SSN values appHcable to the Lp interface are defined in 3GPP TS 23.003. 

8.3.4 Usage of Connectionless SCCP 

Connectionless SCCP messages and procedures shall be used to transfer BSSMAP-LE Connectionless Information 
messages. Refer to 3GPP TS 43.059 for a description of the procedures in the SMLC. SCCP protocol class 1 shall be 
used when multiple BSSMAP-LE messages are sent containing segments of a single fragmented SMLCPP message. 

8.3.5 Usage of Connection Oriented SCCP 

Connection oriented SCCP messages and procedures are not applicable to the Lp interface. 



8.3.6 Contents of the SCCP Data Field 

The contents of the SCCP data field is shown in the following figure. 
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Figure 8.3.6-1/3GPP TS 49.031 : SCCP Data Field for a BSSMAP-LE Message 

The Discrmination Indicator is coded in bit 1 of octet one and indicates the type of the BSSAP-LE message. 



Discrmination Indicator 





BSSAP-LE Message Type 

BSSMAP-LE 



The length indicator is coded in one octet, and is the binary representation of the number of octets of the subsequent 
BSSMAP-LE message parameter. 



9 Message Functional Definitions and Contents 

For each message there is, in this clause, a table listing the signalling elements in their order of appearance in the 
transmitted message. 



£75/ 



3GPP TS 49.031 version 4.3.0 Release 4 



21 



ETSI TS 149 031 V4.3.0 (2002-07) 



9.1 BSSMAP-LE PERFORM LOCATION REQUEST message 

This message is sent to request a location estimate for a target MS and contains sufficient information to enable location 
according to the required QoS using any positioning method supported by the PLMN and, where necessary, MS. The 
message is also used to request LCS assistance data transfer to an MS or request a deciphering keys for LCS broadcast 
assistance data The message can be sent from the BSC to the SMLC. 

Table 9.1 : BSSMAP-LE PERFORM LOCATION REQUEST message content 



Information element 


Type / Reference 


Presence 


Format 


Length in 
octets 


Message type 


IVIessage Type 


M 


V 


1 


Location Type 


Location Type 


M 


TLV 


3-4 


Cell Identifier 


Cell Identifier 


M 


TLV 


3-10 


Classmark Information Type 3 


Classmark Information Type 3 


Q 


TLV 


2-n 


LCS Client Type 


LCS Client Type 


C 


TLV 


3 


Chosen Channel 


Chosen Channel 


Q 


TLV 


2-n 


LCS Priority 


LCS Priority 


Q 


TLV 


3 


LCS QoS 


LCS QoS 


Q 


TLV 


6 


GPS Assistance Data 


GPS Assistance Data 


Q 


TLV 


3-n 


BSSLAP APDU 


APDU 





TLV 


2-n 



9.1.1 Location Type 

This parameter defines the type of location information being requested. 

9.1.2 Cell Identifier 

This parameter gives the current cell location of the target MS. The format shall either be the cell global identification 
or the LAC plus CI form. 

9.1 .3 Classmark Information Type 3 

This parameter indicates the positioning methods supported by the MS as obtained from the MS Classmark 3 received 
earlier from the target MS. 

9.1.4 LCS Client Type 

This parameter defines the type of the originating LCS Client. It shall be included if the Location Type indicates a 
request for a location estimate and may be included in other cases to assist an SMLC to appropriately prioritize a 
location request 

9.1.5 Chosen Channel 

This parameter defines the type of radio channel currently assigned to the target MS. 

9.1.6 LCS Priority 

This parameter defines the priority of the location request. 

9.1.6a LCS QoS 

This parameter provides the required Quality of Service for the LCS Request. Quality of Service may include horizontal 
accuracy, vertical accuracy and allowed response time. 
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9.1 .7 GPS Assistance Data 

This parameter identifies the specific GPS assistance data that may be requested. 

9.1.8 BSSLAPAPDU 

This parameter provides additional measurements (e.g. timing advance) for the target MS from the BSC. The 
measurements are contained inside a BSSLAP APDU. 

9.2 BSSMAP-LE PERFORM LOCATION RESPONSE message 

This message is sent in response to a BSSMAP-LE Perform Location Request to return a successful location estimate 
for a target MS or to indicate some failure in obtaining this. The message is also sent in response to a BSSMAP-LE 
Perform Location Request to return deciphering keys or an indication that LCS assistance data has been successfully 
delivered to an MS. The message can be sent from the SMLC to the BSC. 

Table 9.2: BSSMAP-LE PERFORM LOCATION RESPONSE message content 



Information element 


Type / Reference 


Presence 


Format 


Length in 
octets 


Message type 


IVIessage Type 


M 


V 


1 


Location Estimate 


Geograpliic Location 


C 


TLV 


2-22 


Positioning Data 


Positioning Data 





TLV 


2-n 


Decipliering Keys 


Deciphering Keys 





TLV 


17 


LCS Cause 


LCS Cause 





TLV 


3 



9.2.1 Location Estimate 

This parameter provides a location estimate for the target MS in the case of a successful location attempt. 

9.2.2 Positioning Data 

This parameter provides additional information for the positioning attempt from the SMLC. 

9.2.3 Decipliering Keys 

This parameter provides two deciphering keys that can be used to decode LCS broadcast assitance data by the MS. The 
SMLC shall provide the current deciphering key for the MS's present location. The SMLC shall also provide the next 
deciphering key applicable after the current deciphering key. 

9.2.4 LCS Cause 

The LCS Cause is included if and only if a requested location estimate was not successfully obtained (e.g. location 
estimate not available or does not meet the required QoS), requested deciphering keys were not successfully returned or 
requested LCS assistance data was not successfully transferred to the MS. The parameter provides the reason for the 
failure. If the LCS Cause is included, the Location Estimate and Deciphering Key shall not be included. 

9.3 BSSMAP-LE PERFORM LOCATION ABORT message 

This message is sent by the instigator of a location request to abort the positioning attempt or the request for assistance 
data or deciphering keys. This message can be sent from the BSC to the SMLC. 
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Table 9.3: BSSMAP-LE PERFORM LOCATION ABORT message content 



Information element 


Type / Reference 


Presence 


Format 


Length in 
octets 


Message type 


Message Type 


M 


V 


1 


LCS Cause 


LCS Cause 


M 


TLV 


3 



9.3.1 LCS Cause 

The LCS Cause provides the reason for the aborting the location attempt. 

9.4 Void 



9.5 



Void 



9.6 



Void 



9.7 



Void 



9.8 BSSIVIAP-LE CONNECTION ORIENTED INFORMATION 
message 

This message is sent in association with an existing signaHng connection between an SMLC and another entity to 
transfer information between the SMLC and other entity belonging to a higher level protocol. The message can be sent 
from a BSC to an SMLC and from an SMLC to a BSC. 

Table 9.8: BSSMAP-LE CONNECTION ORIENTED INFORMATION message content 



Information element 


Type / Reference 


Presence 


Format 


Length in 
octets 


Message type 


Message Type 


M 


V 


1 


BSSLAP APDU 


APDU 


M 


TLV 


3-n 


Segmentation 


Segmentation 


C 


TLV 


3 



9.8.1 BSSLAP APDU 

This parameter contains a BSSLAP message. 

9.8.2 Segmentation 

This parameter contains segmentation information for a segmented APDU. The parameter shall not include message 
information. The parameter shall be included if and only if the BSSLAP APDU is segmented. 

9.9 BSSMAP-LE CONNECTIONLESS INFORMATION 
nnessage 

This message conveys signaling information associated with a higher protocol level between an SMLC and another 
entity when there is no existing signaling connection association. The message can be sent from a BSC to an SMLC, 
from an SMLC to a BSC and from an SMLC to another SMLC. 
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Table 9.9: BSSMAP-LE CONNECTIONLESS INFORMATION message content 



Information element 


Type / Reference 


Presence 


Format 


Length in 
octets 


Message type 


IVIessage Type 


M 


V 


1 


Source Identity 


Networl< Element Identity 


M 


TLV 


3-n 


Destination Identity 


Network Element Identity 


M 


TLV 


3-n 


APDU 


APDU 





TLV 


3-n 


Segmentation 


Segmentation 


C 


TLV 


5 


Return Error Request 


Return Error Request 





TLV 


2 


Return Error Cause 


Return Error Cause 





TLV 


3 



9.9.1 Source Identity 

This parameter identifies the original source of the message. The original source can either be an SMLC or a Type B 
LMU. The source is identified by association with either a location area or a cell site. 

9.9.2 Destination Identity 

This parameter identifies the final destination of the message. The final destination can either be an SMLC or a Type B 
LMU. The destination is identified by association with either a location area or a cell site. 

9.9.3 APDU 

This parameter contains an embedded APDU. For information transfer between an SMLC and Type B LMU this shall 
be an LLP APDU. For information transfer between two peer SMLCs, this shall be an SMLCPP APDU. 

9.9.4 Segmentation 

This parameter contains segmentation and message information for a segmented APDU. The parameter shall be 
included if and only if a segmented APDU is present. 

9.9.5 Return Error Request 

This parameter may be included to request an error response if BSSMAP-LE message cannot be delivered successfully 
to its final destination. This parameter shall not be included if the Return Error cause is present. 

9.9.6 Return Error Cause 

This parameter indicates an error response for a BSSMAP-LE connectionless information message that could not be 
delivered to its final destination. The APDU should be present and the same as the APDU in the original undelivered 
message. The source and destination identities shall be included and the same as the destination and source identities, 
respectively, in the original undelivered message. 



9.10 BSSMAP-LE RESET message 



This message is sent to indicate a failure in the sending entity with loss of memory of LMU connections and location 
service transactions that were established or were being established. The message may be sent from an SMLC to a BSC 
and from a BSC to an SMLC. 

This message is sent as a connectionless SCCP message. 
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Table 9.10: BSSMAP-LE RESET message content 



Information element 


Type / Reference 


Presence 


Format 


Length in 
octets 


Message type 


Message Type 


M 


V 


1 


Cause 


Cause 


M 


TLV 


3-4 



9.1 1 BSSMAP-LE RESET ACKNOWLEDGE message 

This message is sent in response to a Reset message to indicate that references and resources associated with LMU 
connections and location service transactions towards the entity sending the Reset have been released. The message 
may be sent from an SMLC to a BSC and from a BSC to an SMLC. 

This message is sent as a connectionless SCCP message. 

Table 9.11 : BSSMAP-LE RESET ACKNOWLEDGE message content 



Information element 


Type / Reference 


Presence 


Format 


Length in 
octets 


Message type 


Message Type 


M 


V 


1 



1 Message format and information element coding 

This clause specifies the coding of the Information Elements used by the BSSAP-LE protocol. The spare bits in the 
coding of an IE shall be set to zero by the sender and shall be ignored by the receiver. 

All unassigned codes (whether omitted or explicitely Unassigned in the text) shall be treated as unknown. 

The following conventions are assumed for the sequence of transmission of bits and bytes: 

Each bit position is marked as 1 to 8. Bit 1 is the least significant bit and is transmitted first. 

In an element octets are identified by number, octet 1 is transmitted first, then octet 2 etc. 

When a field extends over more than one octet, the order of bit values progressively decreases as the octet number 
increases. The least significant bit of the field is represented by the lowest numbered bit of the highest numbered octet 
of the field. 

For variable length elements a length indicator is included, this indicates the number of octets following in the 
element. 

All fields within Information Elements are mandatory unless otherwise specified. The Information Element 
Identifier shall always be included. 

All spare bits are set to 0. 

For any information element of format TLV, the length indicator octet, as in 3GPP TS 48.008, defines the number of 
octets in the information element that follow the length indicator octet. 
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10.1 Message type 



Message type uniquely identifies the message being sent. It is a single octet element, mandatory in all messages. 



Table 10.1/3GPP TS 49.031 : Message type information element 



Category 



87654321 



Message Type 



POSITIONING MESSAGES 



Reserved ( NOTE) 



INFORMATION MESSAGES 



GENERAL MESSAGES 



00000000 Reserved. 

10 10 11 BSSMAP-LE PERFORM LOCATION REOUEST 

10 110 1 BSSMAP-LE PERFORM LOCATION RESPONSE 

10 1110 BSSMAP-LE PERFORM LOCATION ABORT 

1 Reserved (note) 

1 Reserved (note) 

1 1 Reserved (note) 

1 Reserved (note) 

10 10 10 BSSMAP-LE CONNECTION ORIENTED INFORMATION 

1110 10 BSSMAP-LE CONNECTIONLESS INFORMATION 



110 RESET 

00 11000 1 RESET ACKNOWLEDGE 
NOTE: These values of the codepoints shall not be used as they were used in an earlier version of the 
protocol. 



10.2 Information Element Identifiers 

The next list shows the coding of the Information Element Identifiers used in the present document. 
Table 10.2/3GPP TS 49.031 : Information Element Identifier coding 



87654321 


Information element 


Reference 


00111110 


LCS QoS 


10.16 


01000011 


LCS Priority 


10.15 


01000100 


Location Type 


10.18 


01000101 


Geographic Location 


10.9 


01000110 


Positioning Data 


10.20 


01000111 


LCS Cause 


10.13 


01001000 


LCS Client Type 


10.14 


0100100 1 


APDU 


10.3 


010010 10 


Network Element Identity 


10.19 


010010 11 


GPS Assistance Data 


10.10 


01001100 


Deciphering Keys 


10.8 


01001101 


Return Error Request 


10.21 


01001110 


Return Error Cause 


10.22 


01001111 


Segmentation 


10.24 


000100 11 


Classmarl< Information Type 3 


10.7 


00000100 


Cause 


10.4 


00000101 


Cell Identifier 


10.5 


00 100001 


Chosen Channel 


10.6 


00000000 


Reserved (note) 




00000001 


Reserved (note) 




00000010 


Reserved (note) 




0000001 1 


Reserved (note) 




00000100 


Reserved (note) 




NOTE: These values of the codepoints shall not be used as they were used in an 
earlier version of the protocol. 
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10.3 APDU 

This is a variable length information element that conveys an embedded message or message segment associated with a 
higher level protocol. 





8 7 


|6|5|4|3|2|1| 


Octet 1 


lEI 


Octet 2-3 


Length indicator 


Octet 4 


Spare 


Protocol ID 


Octet 5 

to 
Octet n 


The rest of the information element contains a message or 
message segment whose content and encoding are defined 
according to the protocol ID. 



Figure 10.3.1/3GPP TS 49.031 : APDU IE 



Length Indicator (octets 2-3). 



The most significant bit is bit 8 of Octet 2, and the least significant bit is bit 1 in Octet 3. The length indicator defines 
the total number of octets after length indicator. 

Protocol ID (bits 7-1 of octet 4). 



0000000 


reserved 


0000001 


BSSLAP 


0000010 


LLP 


0000011 


SMLCPP 



Embedded Message (octets 5-n) 



BSSLAP 



the embedded message is as defined in 3GPP TS 48.071 



LLP 



the embedded message contains a Facility Information Element as defined in 3GPP TS 44.071 
excluding the Facility lEI and length of Facility IE! octets defined in 3GPP TS 44.071 . 



SMLCPP 



the embedded message is as defined in 3GPP TS 48.031 



10.4 Cause 

This is a variable length information element indicating the reason for sending a Reset message. 



8 7 6 


1 5 1 4 1 


3 1 2 1 1 1 


IE! 


Length indicator 


The rest of the information element is coded 
the Cause IE defined in 3GPP TS 48.008. 


as the value part of 



Octet 1 
Octet 2 
Octet 3 



Figure 10.4.1/3GPP TS 49.031 : Cause IE 

10.5 Cell Identifier 

This is a variable length information element identifying a particular cell. 



Octet 1 
Octet 2 
Octet 3 



8 7 


6 


1 5 1 4 1 


3 


1 2 1 1 1 


IE! 


Length indicator 


The rest of the information element is coded as the value part of 
the Cell Identifier IE defined in 3GPP TS 48.008. 



Figure 10.5.1/3GPP TS 49.031 : Cell Identifier IE 
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10.6 Chosen Channel 



This information element identifiers a type of radio interface channel. 



Octet 1 
Octet 2 
Octet 3 



Figure 10.6.1/3GPP TS 49.031 : Chosen Channel IE 



1 0.7 Classmark Information Type 3 

This information element contains classmark information for a target MS obtained from the MS Classmark 3 defined in 
3GPPTS 24.008. 



8 


7 1 6 1 5 1 4 1 


3 1 


2 1 1 1 


lEI 


Length indicator 


The rest of the information element is coded as the value part of 
the Chosen Channel IE defined in 3GPP TS 48.008. 





8 7 6 5 4 3 2 1 


Octet 1 


IE! 


Octet 2 


Length indicator 


Octet 3 


The rest of the information element is coded as the value part of 
the Classmark Information Type 3 IE defined in 3GPP TS 48.008. 



Figure 10.7.1/3GPP TS 49.031 : Classmark Information Type 3 IE 



10.8 Deciphering Keys 



This information element defines the deciphering keys which should used by the MS to decode LCS broadcast 
assistance data. The parameter includes following data fields. All fields shall be included: 





8 


7 


6 1 5 1 4 1 3 


2 1 1 1 


Octet 1 


IE! 


Octet 2 


Length indicator 


Octet 3 


spare 


Ciphering 
Key Flag 


Octet 4 
Octet 10 


Current Deciphering Key Value 


Octet 11 
Octet 17 


Next Deciphering Key Value 



Figure 10.8.1/3GPP TS 49.031 : Deciphering Keys IE 

Ciphering Key Flag (octet 3) 

This flag indicates the current Ciphering Key Flag used in the LCS assistance data broadcast messages in the location 
area. 

Current Deciphering Key Value (octet 4 - 10) 

Current Deciphering Key contains the 56 bit deciphering key that is currently in use in location area for deciphering the 
LCS assistance data broadcast messages. 

Next Deciphering Key (octet 11 - 17) 

Next Deciphering Key contains the 56 bit deciphering key that will be used next in location area for deciphering the 
LCS assistance data broadcast messages. 
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10.9 Geographic Location 



This is a variable length information element providing an estimate of a geographic location. 



Octet 1 
Octet 2 
Octet 3 

to 
Octet n 



8 



lEI 



Length indicator 



The rest of the information element contains an octet sequence 
identical to that for the Ext-Geographicallnformation data type in 
3GPP TS 29.002. 



Figure 10.9.1/3GPP TS 49.031 : Geographic Location IE 



10.10 GPS Assistance Data 

This is a variable length information element identifying the GPS assistance data requested for an MS. 





8 


7 


6 


5 


4 


3 


2 


1 


Octet 1 


lEI 


Octet 2 


Length indicator 


Octet 3 


H 


G 


F 


E 


D 





B 


A 


Octet 4 


P 





N 


M 


L 


K 


J 


1 


Octet 5 

to 
Octet 
8+2n 


Satellite related data 



Figure 10.10.1/3GPP TS 49.031 : GPS Assistance Data IE 

Octet 3 

bit A Almanac 

0: Almanac is not requested 

1 : Almanac is requested 

bitB UTC Model 

0: UTC Model is not requested 

1 : UTC Model is requested 

bit C Ionospheric Model 

0: Ionospheric Model is not requested 

1 : Ionospheric Model is requested 

bit D Navigation Model 

0: Navigation Model is not requested - octets 5 to 8+2n are not present 

1 : Navigation Model is requested - octets 5 to 8+2n are present 

bit E DGPS Corrections 

0: DGPS Corrections are not requested 

1 : DGPS Corrections are requested 

bit F Reference Location 

0: Reference Location is not requested 

1 : Reference Location is requested 

bit G Reference Time 

0: Reference Time is not requested 

1 : Reference Time is requested 

bit H Acquisition Assistance 

0: Acquisition Assistance is not requested 

1 : Acquisition Assistance is requested 
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8 7 


6 


1 5 1 4 


1 3 1 2 


1 1 


GPS Week 


Spare 


GPS Week 

1 

NSAT 

Spare 


GPS Toe 


NSAT 


T-Toe limit 


spare 


SatID 1 




I0DE1 




spare 


SatID n 




lODE n 



bit I Real-Time Integrity 

0: Real-Time Integrity is not requested 

1 : Real-Time Integrity is requested 

bits J through P are Spare bits 

At least one of bits A, B, C, D, E, F, G, H or I, shall be set to the value "1". 



Octet 5 
Octet 6 



Octet 7 
Octet 8 

Octet 9 
Octet 10 

Octet 7+2n 
Octet 8+2n 

Figure 10.10.2/3GPP TS 49.031 : Coding of Satellite Related Data 

GPS Week (bits 7-8 octet 5 and octet 6) 

This field contains a 10 bit binary representation of the GPS Week of the assistance currently held by the MS. The most 
significant bit of the GPS Week is bit 8 in octet 5 and the least significant bit is bit 1 in octet 6. 

GPS_Toe (octet 7) 

This field contains a binary representation of the GPS time of ephemeris in hours of the newest ephemeris set contained 
in handset memory (range 0-167). 

NSAT (octet 8, bits 5-8) 

This field contains a binary representation of the number of satellites to be considered for the current GPS assistance 
request. If the MS has no ephemeris data, this field shall be set to zero. If the MS has ephemeris data whose age exceeds 
the T-Toe limit, this field may be set to zero. If the SMLC receives a zero value for this field, it shall ignore the GPS 
Week and GPS_Toe fields and assume that the MS has no ephemeris data. 

T-Toe limit (octet 8, bits 1-4) 

This field contains a binary representation of the ephemeris age tolerance of the MS to the network in hours (range 0- 
10). 

SatID X (x = 1,2, ... n) (octet 7 + 2x, bits 1-6) 

This field is present only if NSAT exceeds zero and contains a binary representation of the identity of a satellite for 
which the assistance request is applicable. The number of satellite fields is indicated in the field NSAT. 

lODE X (x = 1,2, ... n) (octet 8 + 2x) 

This field is present only if NSAT exceeds zero and contains a binary representation of the Issue of Data Ephemeris 
held in the MS, which identifies the sequence number for the satellite x (x = 1,2, ..., n). The SMLC shall derive the 
issue date and time for the lODE of each satellite x from the GPS Week and GPS_Toe fields (e.g. when a particular 
lODE value for a satellite x was issued more than once within the period of T-Toe limit). 
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10.11 Void 



10.12 Void 



10.13 LCS Cause 

The LCS Cause parameter is of variable length IE and provides the reason for an unsuccessful location request. 





8 


7 


6 1 5 1 4 1 3 


2 


1 


Octet 1 


lEI 


Octet 2 


Length indicator 


Octet 3 


Cause value 


Octet 4 


Diagnostic value (note) 



NOTE: The inclusion of this octet depends on the cause value. 

Figure 10.13.1/3GPP TS 49.031 : LCS Cause IE 

Table 10.13.1/3GPP TS 49.031 : Cause value 



LCS Cause value (octet 3) 


Bits 




8765432 1 




00000000 


Unspecified 


00000001 


System Failure 


00000010 


Protocol Error 


0000001 1 


Data missing in position request 


00000100 


Unexpected data value in position request 


00000101 


Position method failure 


000001 10 


Target MS Unreachable 


000001 1 1 


Location request aborted 


00001000 


Facility not supported 


00001001 


Inter-BSC Handover Ongoing 


00001010 


Intra-BSC Handover Complete 


0000101 1 


Congestion 


00001 100 




to unspecified in this version of the protocol 


11111111 





Diagnostic value (octet 4): 

this octet may be included if the cause value indicates "position method failure", the binary encoding of this octet 
shall encode the same set of values as defined for the PositionMethodFailure-Diagnostic in 3GPP TS 29.002. 
Values outside those defined in 3GPP TS 29.002 shall be ignored by a receiver. 



10.14 LCS Client Type 

This information element identifies the type of LCS Client. 



8 


|7|6|5|4|3|2|1 1 


lEI 


Length indicator 


Client Category Client Subtype 



Octet 1 
Octet 2 
Octet 3 



Figure 10.14.1/3GPP TS 49.031 : LCS Client Type IE 

The client category (bits 8-5 of octet 3) and the client subtype (bits 4-1 of octet 3) are coded as follows. 
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Client Category 


Client Subtype 


Explanation 


0000 




Value Added Client 




0000 


unspecified 




all values 


reserved 


0010 




PLIVIN operator 




0000 


unspecified 




0001 


broadcast service 




0010 


O&M 




0011 


anonymous statistics 




0100 


Target MS service support (note 1 ) 




other values 


reserved 

note 1 : includes a CAIVIEL phase 3 LCS 

client 


0011 




Emergency services 




0000 


unspecified 




other values 


reserved 


0100 




Lawful Intercept services 




0000 


unspecified 




other values 


reserved 


0101 -1111 


all values 


reserved 



10.15 LCS Priority 



This information element defines the priority level of a location request. 



Octet 1 
Octet 2 
Octet 3 



8 


7 1 6 


1 5 1 4 1 3 


1 2 1 1 1 


IE! 


Length indicator 


This octet is coded as 


the LCS-Priority octet in 


3GPP TS 29.002. 



Figure 10.15.1/3GPP TS 49.031 : LCS Priority IE 



10.16 LCSQoS 

This information element defines the Quality of Service for a location request. 



Octet 1 
Octet 2 
Octet 3 
Octet 4 
Octet 5 
Octet 6 



8 7 


6 


1 5 1 4 1 3 1 


2 


1 1 1 


IE! 


Length indicator 






spare 




1 VERT 1 


HA 


Horizontal Accuracy 


VA 


Vertical Accuracy 


RT 




spare 







Figure 10.16.1/3GPP TS 49.031 : LCS QoS IE 



Octet 3 



VERT = vertical coordinate indicator 

: vertical coordinate not requested 

1 : vertical coordinate is requested 



Octet 4 



bit 8 HA = horizontal accuracy indicator 

: Horizontal Accuracy is not specified 

1 : Horizontal Accuracy is specified 

bits 7-1 Horizontal Accuracy : 

spare (set all zeroes) if HA=0 

set to 7 bit uncertainty code in 3GPP TS 23.032 if HA=1 
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Octet 5 - applicable only if VERT = 1 

bit 8 VA = vertical accuracy indicator 

: Vertical Accuracy is not specified 

1 : Vertical Accuracy is specified 

bits 7-1 Vertical Accuracy : 

spare (set all zeroes) if VA=0 

set to 7 bit uncertainty altitude code in 3GPP TS 23.032 if VA=1 

Octet 6 

bits 8-7 RT = response time category 

00 : Response Time is not specified 

01 : Low Delay 

10 : Delay Tolerant 

1 1 : reserved 

bits 6-1 spare 

10.17 Void 

10.18 Location Type 

This is a variable length information element defining the type of location information being requested. 



Octet 1 
Octet 2 
Octet 3 
Octet 4 



87654321 



lEI 



Length indicator 



Location Information 



Positioning IVIetiiod 



Figure 10.18.1/3GPP TS 49.031 : Location Type IE 

Coding of location information (octet 3): 

00000000 current geographic location 

00000001 location assistance information for the target MS 

00000010 deciphering keys for broadcast assistance data for the target MS 

all other values are reserved 

Positioning Method (octet 4) 

This octet shall be included if the location information in octet 3 indicates "location assistance information for the target 
MS" or "deciphering keys for broadcast assistance data for the target MS" and shall be omitted otherwise. 

00000000 reserved 

00000001 Mobile Assisted E-OTD 

00000010 Mobile Based E-OTD 

00000011 Assisted GPS 
all other values are reserved 



10.19 Network Element Identity 



This is a variable length information element identifying a network element, by association with either a designated cell 
site or a designated location area. 
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8 


7 6 5 4 3 2 1 


lEI 


Length indicator 


spare Identity Discrminator 


Networl< Element Identification 



Octet 1 
Octet 2 
Octet 3 
Octet 4 

to 
Octet n 



Figure 10.19.1/3GPP TS 49.031 : Network Element Identity IE 

Identity Discriminator (bits 4-1 of octet 3) 



0000 
0001 
0100 
0101 



Identification using the MCC + MNC +LAC + CI as defined in 3GPP TS 23.003 
Identification using LAC + CI as defined in 3GPP TS 23.003 
Identification using the MCC + MNC + LAC as defined in 3GPP TS 23.003 
Identification using the LAC as defined in 3GPP TS 23.003 



All other values are reserved. 



Octet 4 

to 
Octet 10 



8 


7 


6 1 5 1 4 1 3 


2 


1 1 


IVICC+MNC+LAC+CI 



Figure 10.19.2/3GPP TS 49.031 : Coding of Network Element Identification using the 

l\flCC+MNC+LAC+CI 

Octets 4 to 10 are coded as the Cell Identification of the Cell Identifier IE for Cell identification discriminator = 0000 
defined in 3GPP TS 48.008. 

Octet 4 

to 
Octet 7 

Figure 10.19.3/3GPP TS 49.031 : Coding of Network Element Identification using the LAC + CI 

Octets 4 to 7 are coded as the Cell Identification of the Cell Identifier IE for Cell identification discriminator = 0001 
defined in 3GPP TS 48.008. 



8 


7 


6 


5 1 4 


3 


2 


1 1 


LAC + CI 





8 


7 


6 


5 


4 


3 


2 


1 


Octet 4 

to 
Octet 6 


MCC+ MNC 


Octet 7 

to 
Octet 8 


LAC 



Figure 10.19.4/3GPP TS 49.031 : Coding of Network Element Identification 
using the MCC + MNC + LAC 

Octets 4 to 8 are coded as the corresponding octets in the Cell Identification of the Cell Identifier List IE for Cell 
identification discriminator = 0100 defined in 3GPP TS 48.008. 





8 


7 


6 


1 5 1 4 1 


3 


2 


1 


Octet 4 


LAC 


Octet 5 


LAC - continued 



Figure 10.19.5/3GPP TS 49.031 : Coding of Network Element Identification using the LAC 

Octets 4 to 5 are coded as the corresponding octets in the Cell Identification of the Cell Identifier List IE for Cell 
identification discriminator = 0101 defined in 3GPP TS 48.008. 
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10.20 Positioning Data 



8 


7|6|5|4|3|2|1| 


lEI 


Length indicator 


spare Positioning Data Discriminator 


Positioning IVIethod 1 




Positioning IVIethod n 



This is a variable length information element providing positioning data associated with a successful or unsuccessful 
locatiomn attempt for a target MS. 

Octet 1 

Octet 2 

Octet 3 

Octets 4-4+m 

Octets ..-4+nm 

Figure 10.20.1/3GPP TS 49.031 : Positioning Data IE 

The positioning data discrminator (bits 4-1 of octet 3) defines the type of data provided for each positioning method: 
0000 indicate usage of each positioning method that was attempted either successfully or unsuccessfully 
all other values are reserved 
Coding of the postioning method octets for positioning data discrminator = 0: 
Octet X 



positioning method 



usage 



Coding of positioning method (bits 8-4): 



00000 

00001 

00010 

00011 

00100 

00101 

00110 

00111 

01000 

to 

01111 

10000 

to 

11111 



Timing Advance 
Reserved ( Note) 
Reserved ( Note) 
Mobile Assisted E-OTD 
Mobile Based E-OTD 
Mobile Assisted GPS 
Mobile Based GPS 
Conventional GPS 

reserved for GSM 



reserved for network specific positioning methods 



Coding of usage (bits 3-1) 



000 
001 
010 
Oil 
100 



Attempted unsuccessfully due to failure or interruption 

Attempted successfully: results not used to generate location 

Attempted successfully: results used to verify but not generate location 

Attempted successfully: results used to generate location 

Attempted successfully: case where MS supports multiple mobile based positioning methods and 

the actual method or methods used by the MS cannot be determined 



NOTE: These values of the codepoints shall not be used as they were used in an earlier version of the protocol. 



10.21 Return Error Request 



The Return Error Request parameter indicates a request from the source of a BSSMAP-LE connectionless information 
message for an error response if the message cannot be delivered to its final destination. 
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8 


7 


6 


5 4 


3 


2 


1 


Octet 1 


lEI 


Octet 2 


Length indicator 


Octet 3 


Return Error Type 



Figure 10.21. 1/3GPP TS 49.031: Return Error Request IE 

Coding of Return Error Type (octet 3): 

00000000 Return an unsegmented APDU or the first segment of a segmented APDU; no Return Error shall 

be sent if no APDU was received or if a subsequent segment of a segmented APDU was received 



00000001 

to 

11111111 



Reserved for future use 



1 0.22 Return Error Cause 

The Return Error Cause parameter provides the reason for unsuccessful delivery of a BSSMAP-LE Connectionless 
Information message to its final destination. 



Octet 1 
Octet 2 
Octet 3 



8 


7 


6 


1 5 1 4 1 


3 


2 


1 1 


lEI 


Length indicator 


Cause value 



Figure 10.22.1/3GPP TS 49.031 : Return Error Cause IE 



Table 10.22.1/3GPP TS 49.031 : Cause value 



Cause value (octet 3) 


Bits 




87654321 




00000000 


Unspecified 


00000001 


System Failure 


00000010 


Protocol Error 


0000001 1 


Destination unknown 


00000100 


Destination unreachable 


00000101 


Congestion 


000001 10 




to 


unspecified in this version of the protocol 


11111111 





10.23 Void 



10.24 Segmentation 

This is a variable length information element that carries information for a segmented APDU. 



Octet 1 

Octet 2 

Octets 3-n 



Figure 10.24.1/3GPP TS 49.031 : Segmentation IE 



8 


7 1 6 1 5 1 4 1 3 1 2 


1 1 


lEI 


Length indicator 


Segmentation and IVIessage Information 
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There are two options for the coding of the Segmentation and Message Information portion; 1 octet containing 
segmentation information only and 3 octets containing segmentation and message information. 

Encoding of Segmentation Information: 

Octet 3 

Figure 10.24.2/3GPP TS 49.031 : Segmentation Information 

Encoding of Segmentation and Message Information: 
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Figure 10.24.3/3GPP TS 49.031 : Segmentation and IVIessage Information 

S (Segmentation Bit, bit 5 of octet 3) 

final segment of a segmented message 

1 non-final segment of a segmented message 

Segment Number (bits 4-1 of octet 3) 

This field contains a 4 bit binary representation of the segment number. The first segment has the value '0000', the next 
'000 r, and so on. 

Message ID (octets 4 and 5) 

This field contains a 16 bit binary representation of the message identity, i.e. values 0-65535 are possible. 

This field is used to identify to which messages different segments belong to. 

10.25 Void 
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Annex A (informative): 
Change history 



Change history 


IVIeeting# 


CR 


Rev 


Subject/Comment 


New Version 


SMG#31 






Version for Release 1999 


8.0.0 


SMG#31bis 


A013 




Addition of Integrity Monitor Status 


8.1.0 


SMG#31bis 


A009 




Addition of missing "LMU Cause" IE 


8.1.0 


SMG#31bis 


A011 


1 


Correction of IVIessage Type Encoding and GPS Assistance Data IE 


8.1.0 


SMG#31bis 


A012 




Addition of Global reset and SCCP error procedures 


8.1.0 


SMG#32 


A016 




Error handling in case requested position method is not supported 


8.2.0 


GP-01 


A018 


1 


Geographic Shape restriction in LCS 


8.3.0 


GP-01 


- 


- 


References to GSIVl xx.xx changed to 3GPP TS xx.xx 


8.3.0 


GP-04 


A019 


2 


New issue to support LCS (Rel 4) 


49.031 V4.0.0 


GP-06 


004 




Correction of Location Type IE length in BSSMAP-LE PERFORM 
LOCATION REOUEST message (Rel-4) 


4.1.0 


- 


- 


- 


Editorial corrections (2"'" October 2001) 


4.1.1 


GP-07 


007 




Define lE's order of appearance in BSSAP-LE message 


4.2.0 


GP-07 


009 




Removal of invalid crossreference. 


4.2.0 


GP-07 


015 


1 


Define number of keys in Deciphering Keys IE 


4.2.0 


GP-10 


020 


1 


Clarify Requested GPS Assistance Data IE 
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